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The  clear  precursor  to  fundamental  changes  in  tactics,  technology,  and  com¬ 
munity  norms  is  the  design  of  new  concepts  of  operations  (CONOPS).  Devel¬ 
opment  of  a  CONOPS  is  a  low-cost  activity,  but  it  has  the  power  to  change 
the  direction  of  an  entire  enterprise.  The  current  CONOPS  for  medium-altitude  re¬ 
motely  piloted  aircraft  (RPA)  in  which  the  Air  Force  is  deeply  entrenched  has 
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driven  budgets,  manpower,  requirements,  and  technological  development  for 
nearly  two  decades.  To  enable  progression,  the  Air  Force  must  reform  its  philosophy 
of  how  it  procures  RPA  technology.  Despite  a  fiscal  environment  that  is  prohibitive 
for  development  of  an  entirely  new  next-generation  RPA  system,  the  service  can 
use  existing  assets  to  realize  a  vast  improvement  in  capability  through  changes  in 
software  architecture  and  digital  data-linking  of  RPAs.  An  open-architecture  RPA 
system  can  harness  the  natural  rate  of  technological  progression  in  industry  and 
reverse  the  currently  defunct  RPA  acquisition  process,  wherein  new  technology 
drives  requirements,  back  to  a  state  of  requirements  driving  technological  develop¬ 
ment.  Only  then  can  the  Air  Force  resume  its  responsibility  to  lead  industry  in  the 
development  of  RPA  technology  and  break  free  of  a  sole-source  paradigm. 

Definitions 

A  CONOPS  is  a  written  statement  or  graphical  depiction  that  clearly  and  con¬ 
cisely  expresses  what  the  joint  force  commander  intends  to  accomplish  and  how  it 
will  be  done  using  available  resources.1  Today's  prevalent  RPA  CONOPS  can  be  de¬ 
fined  as  analog  control  by  a  pilot  and  a  sensor  operator  of  an  armed  aircraft  for  a  24/7 
combat  air  patrol  to  support  combatant  commanders  with  armed  reconnaissance  of  time- 
sensitive  targets.  Remote  split  operations  (RSO)  is  a  subset  of  this  CONOPS,  requiring 
launch-and-recovery  and  mission-control  elements  to  allow  nondeployed  personnel 
to  conduct  the  combat  sorties. 

Requirements  are  broadly  defined  capabilities  that  must  be  available  to  execute 
the  overarching  CONOPS.  RPAs  must  provide  full  motion  video  and  signals  intelli¬ 
gence  (SIGINT)  capabilities  to  fulfill  their  intelligence,  surveillance,  and  reconnais¬ 
sance  role  for  combatant  commanders.  They  have  to  be  armed  to  react  kinetically 
to  fleeting  targets,  and  they  must  do  so  24  hours  a  day.  Thus,  requirements  start 
with  meeting  a  needed  mission  capability,  allowing  multiple  solution  options,  and 
potentially  capturing  the  creativity/efficiency  of  industry  and  joint  partners.  De¬ 
fined  requirements  are  then  broken  down  to  second-  and  third-order  parameters 
and  attributes  that  are  the  basis  for  purposefully  engineering  the  system.  With  the 
aforementioned  requirements,  designers  of  today's  RPAs  selected  high-aspect  ratio 
wings  and  efficient  motors  for  long  endurance,  hard  points  for  weapons,  and  a  data 
bus  to  integrate  a  Multi-Spectral  Targeting  System  and  other  sensors.2  Theoretically, 
everything  from  software  to  aircraft  design  to  command  and  control  should  trace 
back  to,  and  be  justified  by,  a  requirement. 

The  earliest  antecedents  of  what  the  Air  Force  now  terms  RPAs  originated  just 
prior  to  World  War  One;  however,  only  in  the  last  20  years  has  the  RPA's  potential  in 
the  context  of  transnational  security  challenges  become  readily  apparent.3  The  de¬ 
velopment  of  RSOs  allowed  the  intelligence  community  to  control  reconnaissance 
platforms  in  real  time  anywhere  on  the  globe.  These  operations,  combined  with 
highly  fuel-efficient  aircraft,  offer  an  unprecedented  level  of  persistence  that  re¬ 
mains  the  primary  advantage  of  the  RPA.  In  2001,  when  Big  Safari— the  Air  Force's 
program  office  charged  with  rapid  development,  procurement,  and  fielding— 
launched  the  first  Hellfire  missile  from  an  MQrl  Predator,  the  armed  scout  CONOPS 
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was  born,  shaping  the  face  of  the  modern  RPA  enterprise.4  The  emergence  of  that 
CONOPS  is  a  brilliant  success  story  in  the  Air  Force's  acquisition  history.  Combatant 
commanders  recognized  the  necessity  of  the  previously  exclusive  intelligence,  sur¬ 
veillance,  and  reconnaissance  aircraft  kinetically  reacting  to  the  targets  it  had 
located.  A  shotgun  acquisition  and  capabilities  implementation  followed,  but  this 
success  story  was  the  last  of  its  kind  for  the  medium-altitude  RPA  enterprise. 

Paralyzed  by  Success 

The  development  of  RPA  CONOPS  stagnated  in  the  early  2000s,  but  the  Predator's 
early  triumphs  outshined  any  concern  for  the  need  of  further  evolution.  General 
Atomics  Aeronautical  Systems  Incorporated  (GA-ASI)  production  reached  full 
capacity,  combatant  commanders  had  an  insatiable  demand  for  this  new  breed  of 
capability,  and  phrases  like  Predporn  and  drone  strike  became  household  terms.5 
Cameras  improved,  a  variety  of  accessories  hung  from  the  wings,  and  the  follow-on 
MCf-9  Reaper  emerged  to  carry  even  more  equipment.  For  a  system  at  the  develop¬ 
mental  stage  of  advanced-technology  demonstrator,  the  Predator  was  quite  possibly 
the  largest  and  fastest  asset  acquisition  in  Air  Force  history.  It  seemed  to  represent 
a  dream  come  true:  the  service  got  a  whole  fleet  of  aircraft  systems  without  paying 
the  time  or  money  bills  for  the  laborious  and  bureaucratic  acquisition  process. 
However,  the  hidden  costs  and  consequences  of  this  approach  manifest  themselves 
throughout  the  asset's  service  life.  The  Predator  arrived  in  the  active  Air  Force  in¬ 
ventory  as  a  rapidly  procured  prototype  lacking  any  standing  requirements  and  in¬ 
cluding  its  own  implicit  CONOPS.  The  early  performance  of  the  system  led  to  an 
explosion  in  production  that  the  Air  Force  was  then  charged  with  managing.  An  asset 
designed  with  the  intention  of  limited  covert  use  suddenly  faced  oversight  and  stan¬ 
dards  endemic  to  a  multi-billion-dollar  military  acquisition  program. 

GA-ASI,  a  fledgling  company  only  a  few  short  years  before,  had  to  adhere  to  govern¬ 
ment  oversight  and  standards  for  airworthiness,  production,  safety,  sustainment, 
software,  and  training,  all  of  which  are  substantially  time  consuming,  expensive, 
and  not  part  of  the  original  contract  for  the  system.6  The  rapid  procurement  of  the 
Predator  and  Reaper  system  led  to  its  classification  as  experimental  in  terms  of  air¬ 
worthiness,  an  inefficiency  that  forced  a  need  for  certificates  of  authorization  issued 
by  the  Federal  Aviation  Administration  anytime  the  Air  Force  wished  to  transit 
through  the  national  airspace.  This  practice  limits  RPA  systems  to  tight  corridors 
between  bases  and  military  operating  areas  to  keep  them  safely  separated  from  civil 
aviation.  The  initial  intent  of  the  system  for  limited  covert  use  in  military-controlled 
airspaces  did  not  require  developmental  test  and  evaluation  documentation  neces¬ 
sary  for  a  Title  10  airworthiness  certificate.  Now  that  the  Predator  and  Reaper  have 
moved  from  covert  to  more  conventional  use,  the  Air  Force  is  facing  greater  need 
for  standard  airworthiness  certification.  The  Predator  and  Reaper  program  office 
has  responsibility  for  future  production  and  retroactive  contracts— that  is,  the  ser¬ 
vice  now  spends  millions  of  dollars  to  generate  developmental  test  and  evaluation 
documentation  to  prove  airworthiness  for  a  system  with  over  two  million  flight 
hours!  Beyond  the  obvious  and  seemingly  nonsensical  insistence  from  the  acquisition 
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process  to  document  for  the  sake  of  documentation,  the  Predator  program  had  two 
distinct  effects.  First,  it  did  succeed  in  providing  weapons,  sensors,  and  a  follow- 
on  airframe  that  significantly  improved  the  utility  of  the  original  Predator  A  and 
brought  the  armed  scout  CONOPS  to  full  maturity.  Second,  it  secured  the  future 
of  GA-ASI  as  the  Air  Force's  sole-source  provider  for  manufacturing,  sustainment, 
and  future  development. 

Air  Force  efforts  to  write  requirements  that  could  evolve  the  armed  scout  mission 
and  begin  to  break  free  of  the  sole-source  paradigm  have  been  unable  to  move  for¬ 
ward.  For  example,  an  operational  RPA  squadron  was  tasked  to  implement  a  GA-ASI 
proprietary  multiaircraft  control  system,  but  its  attempts  were  unsuccessful.7  The 
Air  Force  could  not  compete  the  requirement  on  the  open  market  because  of  soft¬ 
ware  licensing  restrictions,  thus  forcing  the  service  either  to  purchase  the  GA-ASI 
solution  or  face  the  seemingly  insurmountable  cost  of  buying  out  proprietary  soft¬ 
ware  rights.  The  fate  of  the  multiaircraft  control  system  was  further  exacerbated 
when  it  was  employed  by  a  squadron  in  “surge"  state.  The  result  was  an  abbreviated 
syllabus  that  did  not  allow  operators  to  gain  enough  experience  with  the  system  to 
use  it  skillfully.  Ultimately,  the  initial  cadre  of  pilots  with  limited  experience  aban¬ 
doned  the  system  because  they  did  not  “trust"  it  and  because  their  burden  of  opera¬ 
tions  did  not  give  them  the  time  required  to  employ  it  properly.8  The  following 
analogy  best  describes  the  present  state  and  potential  future  of  the  medium-altitude 
RPA  enterprise: 

Imagine  a  group  of  men  cutting  their  way  through  a  jungle  with  machetes.  They're  the 
producers,  the  problem  solvers.  They're  cutting  their  way  through  the  undergrowth, 
clearing  it  out.  The  managers  are  behind  them,  sharpening  their  machetes,  writing  policy 
and  procedures  manuals,  holding  muscle  development  programs,  bringing  in  improved 
technologies  and  setting  up  working  schedules  and  compensation  programs  for  machete 
wielders.  One  day  a  man  climbs  the  highest  tree,  surveys  the  situation  and  yells,  “Wait! 
We're  in  the  Wrong  Jungle!"  But  how  do  the  busy  efficient  producers  and  managers  often 
respond?  “Shut  up!  We  are  making  progress."9 

The  Air  Force  worked  diligently  to  meet  the  ambitious  65  combat  air  patrol  de¬ 
mand  set  by  the  secretary  of  defense.10  Some  of  the  Air  Force's  best  tacticians  have 
eloquently  formulated  and  distilled  stunningly  brilliant  tactics,  techniques,  and  pro¬ 
cedures  (TTP)  to  enable  the  Predator  to  perform  operational  tasks  and  entire  mission 
sets  that  the  system's  designers  never  imagined.  The  Predator  program  office  is  engi¬ 
neering  block  upgrades  full  of  improvements,  fixes,  and  new  technologies.11  Several 
Reserve  and  Guard  units  convert  from  legacy  airframes  to  RPAs  every  year.  The  Air 
Force  developed  an  entirely  new  pilot  training  program  to  teach  officers  how  to  fly 
the  Predator  and  Reaper.12  An  entire  career  field  has  been  established,  centered  on 
the  GA-ASI-branded  medium-altitude  RPA  enterprise.  But  all  of  these  advancements 
are  still  just  polishing  the  same  two-decades-old  CONOPS,  feeding  the  sole-source 
paradigm,  and  cutting  deeper  and  deeper  into  the  wrong  proverbial  jungle. 

The  military  research  and  development  (R£?D)  community  has  danced  around 
the  next-generation  RPA  CONOPS  through  technology  demonstration  for  several 
years.  Individual  programs  have  developed  key  enabling  technologies  such  as  sense 
and  avoid,  automated  aerial  refueling,  man-to-machine  interfaces,  machine-to-machine 
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interfaces,  multiaircraft  control,  and  autonomy.13  All  are  fragments  of  requirements 
of  a  future  CONOPS.  The  key  mistake  has  been  to  focus  on  these  individual  tech¬ 
nologies  and  attempt  to  apply  them  to  the  armed  scout  CONOPS.  Why  have  all  of 
these  technologies  not  made  their  way  into  the  Predator  or  Reaper  systems?  The 
sole-source  paradigm  makes  innovation  difficult  because  even  when  the  contractor 
enjoying  the  monopoly  legitimately  offers  new  functionality,  service  culture  can 
still  reject  it  without  explanation.  This  practice  is  a  manifestation  of  the  danger  of 
not  having  a  clear  CONOPS  to  drive  government  requests  to  the  market,  instead 
having  the  market  proffer  features  and  functionality.14  Specifically,  something  as 
straightforward  as  auto  takeoff  and  land  (AT£tL)  has  yet  to  be  implemented  on  Air 
Force  Predators  and  Reapers  even  though  the  Army  has  successfully  employed 
AT&'L  on  the  GA-ASI-produced  Grey  Eagle  system  for  years.  The  RCf-4  Global  Hawk 
almost  exclusively  utilizes  the  feature,  and  the  Navy's  X-4 7  is  making  autonomous 
landings  on  aircraft  carriers.15  According  to  Gen  John  P  Jumper,  former  Air  Force 
chief  of  staff, 

We  have  allowed  the  pilot  culture  (fly  the  vehicle)  to  dominate  what  should  have  evolved 
into  technologies  that  minimize  the  need  for  individual  aircraft  control.  We  should  be  try¬ 
ing  to  maximize  the  larger  effects  of  automated  flight  and  sensor  functions,  allowing  the 
grouping  of  air  vehicles  when  appropriate,  developing  more  advanced  mission  planning 
software  and  enabling  automated  mission  execution.  .  .  .  What  has  evolved  is  an  RPA 
world  that  continues  to  be  overly  concerned  with  input  rather  than  the  output,  persisting 
with  more-than-necessary  man-in-the-loop,  and  less  than  necessary  integration  of  sensors 
and  machine-to-machine  capabilities  automated  for  mission  success.  It  is  only  logical  that 
the  next  generation  mission  effectiveness  will  strive  to  fully  develop  the  spectrum  of  RPA 
capabilities  most  valued  by  commanders,  shift  to  an  output,  mission  oriented  doctrine 
and  allow  automation  to  ease  the  emerging  burden  on  manpower,  training,  bandwidth 
management,  etc.16 

John  Boyd  warned  of  the  dangers  of  a  culture  that  clings  to  an  outdated  standard. 
His  paper  “Creation  and  Destruction”  describes  how  organizations  that  adhere  to 
standards  and  concepts  which  rule  constituent  elements  will  progress  to  a  state  of 
disorder  as  new  elements  are  added  to  the  domain.17  In  other  words,  an  organiza¬ 
tion  that  adheres  to  one  particular  CONOPS  without  the  ability  and  foresight  to  assess, 
strategically  forecast,  select,  and  formulate  an  appropriate  CONOPS  for  the  situation— 
and  then  drive  action— will  see  an  increasing  level  of  complexity  and  confusion  in 
their  TTPs  as  new  perceptions  and  technologies  emerge.  According  to  Boyd,  the 
only  way  to  escape  this  slide  toward  entropy  is  to  allow  the  concept  to  collapse  by 
abandoning  the  old  standard  and  permitting  the  emergence  of  a  new  domain  by 
finding  common  attributes  and  qualities  among  the  constituents  of  the  former  stan¬ 
dard  and  creating  a  new  standard.  Put  concisely,  an  organization  eventually  has  to 
abandon  the  old  CONOPS  and  leverage  emerging  TTPs  and  technology  to  form  a 
new  one.  The  alternative  is  to  face  an  ever-increasing  state  of  complexity  and  con¬ 
fusion  while  trying  to  integrate  new  technologies  into  a  construct  in  which  they  do 
not  fit. 
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Casting  a  Vision 

Intuitively,  developing  a  new  CONOPS  sounds  like  an  investment  of  years  of  work 
and  billions  of  taxpayer  dollars,  particularly  at  the  mention  of  a  word  like  autonomy— 
but  that  is  hardly  the  case.  The  cost  of  a  CONOPS  is  critical  thinking  more  than 
anything  else.  Such  concepts  are  ways  of  reasoning  to  produce  guidance  that  can 
drive  requirements  which  in  turn  lead  to  technological  development.  Budgets  for 
technology  development  have  already  been  executed  (e.g.,  AT£tL,  sense  and  avoid, 
etc.),  but  the  concept  of  how  the  Air  Force  employs  these  technologies  (i.e.,  input 
over  output)  is  the  limiting  factor  that  needs  to  be  reformed.18  Air  Force  leadership 
must  turn  the  RPA  enterprise  around  from  contractor-developed  technology  that 
drives  requirements  and  CONOPS  to  having  the  service  lead  technology  through 
defined  future  CONOPS  and  subsequent  forward-looking  requirements.  The  alter¬ 
native  is  to  remain  locked  in  the  sole-source  paradigm  for  the  foreseeable  future. 

As  an  example  of  a  proper  flow  from  forecasting  and  strategizing  to  CONOPS  de¬ 
velopment  to  technical  design,  consider  autonomous  mission  planning  and  execu¬ 
tion  (AMPLEX).  In  this  notional  design,  a  mission  director  tells  the  AMPLEX  system 
a  set  of  objectives,  and  the  system  generates  a  multiaircraft  sortie  flow  with  accom¬ 
panying  mission  routing  for  review.  The  director  approves,  and  the  system  autono¬ 
mously  executes  and  adjusts  in  real  time  to  manage  allowable  performance  devia¬ 
tions.  The  difference  between  AMPLEX  and  today's  RPA  employment  is  that  the 
operator  is  a  “human  on  the  loop,"  not  a  “human  in  the  loop."  Although  this  descrip¬ 
tion  may  appear  simplistic,  that  is  precisely  the  purpose  of  a  CONOPS:  to  effec¬ 
tively  articulate  the  key  facets  and  avoid  becoming  entrenched  in  technical  or  tactical 
details.  It  is  the  on-ramp  back  onto  the  highway  of  technological  progression  and 
the  right  proverbial  jungle  to  begin  cutting  through. 

A  CONOPS  like  AMPLEX  would  inform  and  orient  requirements,  and  require¬ 
ments  would  drive  technological  development,  resetting  the  government-industry 
relationship  to  one  of  government  leading  industry.  The  technological  pillars  of  an 
AMPLEX  CONOPS  already  exist  in  higher-technology  readiness  levels  than  the 
Predator's  systems  when  it  was  first  deployed;  however,  adoption  of  the  approach 
has  stagnated  because  these  technologies  are  difficult  to  integrate  into  a  proprie¬ 
tary,  closed  technical  ecosystem  that  dominates  the  armed  scout  CONOPS.19  Ini¬ 
tially,  AMPLEX  can  be  realized  without  upgrading  any  major  hardware,  without 
building  new  aircraft  or  facilities,  and  by  utilizing  the  command  and  control  infra¬ 
structure  already  in  place.  The  stumbling  block  is  the  sole-source  paradigm:  monopo¬ 
listic  control  of  the  software  architecture  and  a  laborious  software  update  process 
that  would  otherwise  not  survive  open-market  competition.  Software,  more  specifi¬ 
cally  ground  control  station  (GCS)  software,  is  pivotal  in  redefining  modern  aircraft 
capabilities,  and  it  is  the  major  element  of  change  that  the  AMPLEX  CONOPS 
would  drive. 

There  are  a  multitude  of  self-inflicted  barriers  to  this  level  of  innovation,  including 
RPA  community  perceptions,  disconnects  between  operational  and  R<SD  entity  efforts, 
and  subtle  incentives  for  leaders  within  the  community  to  maintain  the  status  quo 
rather  than  foster  a  culture  of  innovation.  The  tendency  among  experienced  RPA 
operators  is  to  quickly  reject  the  prospect  of  autonomy.  A  standard  concern  is  that 
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the  crew  will  become  overly  dependent  on  autonomous  aids  that  in  turn  will  lead 
to  poor  preparation  to  execute  complex  mission  sets  if  the  autonomous  features 
ever  become  unavailable.  This  argument  communicates  a  valid  concern  from  a 
near-term  point  of  view,  but  from  a  mid-to-long-term  perspective,  it  is  historically 
accurate  to  say  that  reliance  on  technology  for  enhanced  mission  success  is  a  gradual 
process  of  rejection,  caution,  acceptance,  and,  eventually,  dependence.  Currently, 
while  performing  cognitively  demanding  maneuvers,  aircrews  are  utterly  depen¬ 
dent  on  autopilot  functions  such  as  the  stability  augmentation  system  and  autopilot 
hold  modes.  Stakes  would  have  to  be  very  high  to  consider  an  RPA  for  continuous 
use  in  collection  or  weapons  employment  while  autopilot  functions  were  malfunc¬ 
tioning,  yet  people  who  fear  more  advanced  automation  ignore  the  reality  of  their 
present  dependence.  Similarly,  the  community  utilizes  a  host  of  supporting  soft¬ 
ware  that  practitioners  deem  vital  for  flight  safety,  mission  management,  and  valida¬ 
tion  of  the  weapon  employment  zone.  Aircrews  are  allowed  to  depend  on  autopilot 
and  peripheral  tools  because  they  have  proven  highly  reliable  over  a  large  swath  of 
the  system's  more  than  two  million  flight  hours  and  greatly  aid  effective  accom¬ 
plishment  of  the  RPA  mission. 

The  vision  and  achievements  of  the  K&'D  community  have  advanced  so  far  beyond 
current  operational  capabilities  that  crews  get  discouraged  when  they  become 
aware  of  the  wonderful  options  that  already  exist  but  are  not  available  on  their  air¬ 
craft.20  Such  disparity  leaves  the  impression  that  they  will  never  employ  technolo¬ 
gies  such  as  autonomous  teaming,  multiaircraft  control,  artificial  logic  and  decision 
making,  and  so  forth.  It  is  important  to  understand  the  need  for  tailorable  autonomy 
levels  to  afford  the  opportunity  to  build  operational  trust  in  new  automated  func¬ 
tions  cautiously.21  All  of  these  features  are  technically  mature  but  require  giant 
leaps  forward  in  RPA  CONOPS  and  TTPs  to  bring  them  into  operational  use.22  Miss¬ 
ing  is  abridge  between  the  current  set  of  TTPs,  accepted  norms,  training,  and  tech¬ 
nology  and  the  ever-evolving  state  of  the  art. 

The  New  Domain 

Unbeknownst  to  some  community  leaders,  its  members  have  already  begun 
building  such  a  bridge!  Through  auditing  and  processing  of  the  Predator  and  Reaper 
systems'  exploitation  support  data  (real-time  aircraft  and  sensor  payload  telemetry) 
and  digital  terrain  elevation  data  (database  of  terrain  and  elevation  values  used  by 
the  system),  some  astute  operators  have  constructed  a  series  of  basic  piloting  aids— 
the  first  steps  to  trusting  autonomy.  Initially,  these  tools  were  a  quick  reference  for 
aircraft-sensor  look  angles  as  well  as  flight  data  such  as  airspeed,  heading,  and  alti¬ 
tude.  Additionally,  the  tools  supplied  data  such  as  target  coordinates,  elevation,  and 
aircraft  height  above  target.  Not  only  was  the  tool  capable  of  supplying  pilots  with 
these  data  sets  for  their  own  aircraft  but  also  they  could  select  other  aircraft  in  the 
network  and  pull  their  data  as  well.  Next,  the  exploitation  support  data  was  used  to 
derive  tailored  two-dimensional  visual  representations  of  relevant  elements  of  the 
tactical  situation,  continuously  updated  based  upon  aircraft  altitude  and  bank  angle. 
Currently,  these  tools  have  been  programmed  to  provide  predictive  position  points 
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based  upon  aircraft  turning  radius  and  current  winds  to  aid  pilots  in  more  precise 
attack  positioning.23  The  tool  has  been  accepted  with  open  arms  in  the  pilot  com¬ 
munity  as  a  situational  awareness  asset  that  will  lighten  a  pilot's  cognitive  load  during 
complex  maneuvers.  However,  the  community  at  large  does  not  see  past  using 
these  tools  as  visual  aids  and  quick  references  for  data.  Pilots  and  operational  leader¬ 
ship  argue  ad  nauseam  about  button  positioning  and  functionality,  color  coding, 
and  optimal  tool  positioning  for  pilot  cross-check.  They  fail  to  recognize  that  it 
would  be  advantageous  to  abandon  such  tedious  and  time-consuming  exercises  and 
instead  envision  the  revolutionary  capabilities  that  expanding  upon  tools  like  these 
could  provide  in  the  near  term. 

An  intuitive  next  step  is  to  visually  represent  a  continuously  updating  “predic¬ 
tive"  flight  path  arc  based  upon  current  winds  and  commanded  bank  angle  in  two 
dimensions.  A  further  progression  would  overlay  a  three-dimensional  steering  line 
on  the  video  feed  of  the  pilot's  head-up  display  (HUD)  that  would  indicate  turning 
cues  and  finite  steering  paths  for  optimal  positioning.  The  pilot's  current  cross¬ 
check  of  eight  monitors  would  be  virtually  eliminated  by  something  as  simple  as  en¬ 
abling  the  primary  HUD  screen  to  have  a  selectable  overlay  source  input  or  utiliza¬ 
tion  of  a  tool  like  Google  Glass  that  would  permit  the  selection  and  display  of 
third-party  overlay  software  of  the  kind  proposed  here.24  On  the  sensor-operator 
side  of  the  GCS,  a  similar  overlay  capability  on  that  station's  HUD  might  include  a 
pointer  to  another  payload's  target.  For  example,  having  an  arrow  pointing  in  the 
direction  of  where  another  aircraft  is  looking  with  its  sensor  and  then  including  a 
floating  box  on  the  sensor's  screen  that  hovers  over  a  vehicle  that  the  other  aircraft 
was  following  would  make  the  tactical  task  of  passing  custody  of  a  target  infinitely 
easier.  Additionally,  the  software  can  and  should  allow  manipulation  by  targeting 
officers.  They  should  be  able  to  drop  target  coordinates  in  the  system;  assign  collec¬ 
tion  goals  such  as  desired  look  angle,  standoff  distance,  and  camera  type;  and  then 
assign  specific  aircraft  to  these  targets  based  upon  load-out  (of  ammunition), 
unique  capabilities,  and  availability  with  respect  to  maintenance  status.  The  system 
would  then  visually  represent  the  target  and  collection  parameters  and  notify  the 
selected  aircraft  of  the  new  target.  This  capability  is  a  fundamental  shift  in  the 
norms  of  RPA  collection  from  considering  what  the  aircraft  and  aircrew  can  provide 
to  what  the  supported  unit  wants  from  a  target.  It  is  a  perspective  change  that  shifts 
the  focus  from  crew  input  to  desired  customer  output. 

Everything  discussed  thus  far  constitutes  a  basic  exercise  of  graphical  user  inter¬ 
face  and  information  networking.  If  handled  by  the  right  contractor,  it  represents 
fewer  than  six  months  of  work  to  build,  test,  and  implement.  The  system  currently 
used  by  the  operational  community  was  developed  by  a  single  pilot  in  his  spare 
time  on  his  home  computer  over  several  months.25  The  giant  leap  forward  in  RPA 
capability  and  TTPs  is  closer  than  most  operators  realize.  For  example,  one  could 
amend  the  hypothetical  software  package's  requirements  (that  have  thus  far  been 
extremely  simple)  to  include  the  ability  to  assign  a  continuously  updating  series  of 
Global  Positioning  System  coordinates  and  waypoints  to  its  predictive  flight  paths 
and  payload  cues.  These  cues  create  holding  patterns  based  upon  customer-desired 
collection  parameters  such  as  look  angle,  standoff  distance,  and  SIGINT  effects. 
Starting  at  the  customer's  list  of  prioritized  targets  (with  desired  collection-parameter 
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information),  the  system  builds  the  optimal  orbits  and  recommended  aircraft  capa¬ 
bilities  and  load-outs.  It  then  generates  transit  missions  to  and  from  a  home  airfield 
to  the  target,  utilizing  knowledge  from  the  air  tasking  order  or  along  air  traffic  con¬ 
trol  preassigned  common  routes  while  continually  monitoring  the  fuel  needed  for 
the  return  trip.  Lost-link  contingency  routes  (a  series  of  autopilot  waypoints  that 
pilots  currently  set  by  hand  for  the  aircraft  to  follow  to  return  to  base  in  the  event 
of  the  total  failure  of  satellite  links)  would  automatically  follow  the  aircraft  from  tar¬ 
get  to  target  and  maintain  a  safe  routing  to  the  recovering  base.  Its  data  sources 
would  include  weather,  restricted  operating  zones,  and  air  traffic  control  activity, 
eliminating  the  need  for  the  pilot  to  continuously  update  the  routing.  In  today's 
configurations,  the  only  thing  separating  the  system  from  direct  control  of  the  air¬ 
craft  is  the  pilot.  The  missing  link  is  the  ability  of  the  third-party  software  to  inter¬ 
face  bidirectionally  with  the  present  GCS  software.  If  the  Air  Force  were  to  order  a 
software  update  that  allowed  the  GCS  to  accept  console  commands  from  a  securely 
authenticated  alternate  source  other  than  the  stick,  rudder,  and  throttle,  the  aircraft 
could  follow  third-party  system  cues,  sidestepping  the  proprietary  portions  of  the 
system  and  unlocking  the  RPA's  true  potential. 

Thus  begins  the  process  of  rejection,  caution,  acceptance,  and  dependence  on 
new  technology.  Initially,  the  system  will  produce  flight  paths  for  pilots  to  review 
and  either  accept  or  reject.  The  pilot  would  choose  whether  or  not  to  allow  the  system 
to  generate  operational  and  contingency  routing  and  upload  them  to  the  GCS.  Dur¬ 
ing  the  period  of  caution,  features  (perhaps  best  thought  of  as  “apps")  could  be 
added  to  the  systems'  “playbook"— such  as  specific  collection  maneuvers,  optimal 
SIGINT  collection  orbits,  or  even  time-on-target  maneuvering  for  weapons  employ¬ 
ment  (with  respect  to  aircraft  positioning  only,  not  actual  weapons  release).  The 
level  of  automated  functions  should  be  tailorable— an  autonomy  “dial"  that  lets  op¬ 
erators  choose  how  much  or  how  little  to  be  involved  in  the  direct  control  of  the 
system.  After  a  period  of  time,  caution  will  evolve  into  acceptance,  community 
norms  will  direct  pilots  to  use  the  system,  and  it  would  be  taught  to  new  pilots  as 
the  primary  approach  to  mission  management.  Eventually,  the  community  would 
become  dependent  on  the  AMPLEX  system  for  most  of  the  dull,  tedious  mission 
sets.  The  days  of  manually  entering  waypoints  to  build  erratically  behaving  naviga¬ 
tional  routes  using  original  proprietary  software  would  become  a  distant  memory. 

The  third-party  system  described  is  an  open-architecture  software  construct  that 
will  not  only  allow  for  monumental  leaps  forward  in  autonomous  functions  but  also 
lead  to  rapid  integration  of  new  capabilities.  The  first  and  most  important  capability 
it  can  facilitate  is  the  integration  of  Link  16  (tactical  digital  information  link  [TADIL-J]) 
or  other  air/ ground-to-air  data  links  to  the  RPA  community.  The  limiting  factor, 
once  again,  is  the  ability  of  the  third-party  system  to  take  command  of  the  aircraft 
and  sensor  payload.  Aircraft  equipped  with  Link  16  have  the  option  of  slaving  their 
sensor  payloads  to  Link  16  coordinates  and  autoslew  to  view  or  mark  a  target.  The 
same  function  is  needed  on  board  the  RPA  lest  the  almost  instantaneous  process  of 
machine-to-machine  cueing  between  Link  16  and  targeting  pods  be  bogged  down  by 
machine-to-human-to-machine  interfacing  and  manual  input  of  target  coordinates. 
Similarly,  ground-based  customers  able  to  view  the  video  feed  via  the  remotely  op¬ 
erated  video  enhanced  receiver  (ROVER)  could  hypothetically  take  control  of  the 
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payload  to  quickly  gain  situational  awareness  of  their  surroundings  as  well  as  per¬ 
sonally  verify  locations  of  friendly  and  enemy  forces.  This  CONOPS  would  replace 
the  current  practice  of  Army,  Marine,  and  special  forces  customers  having  to  ver¬ 
bally  “talk-on”  sensor  operators  to  targets. 

Interlinking  RPAs  and  enabling  target  coordinates  to  flow  quickly  between  air 
and  ground  assets,  in  addition  to  utilizing  open-architecture  GCS  mission  software, 
will  allow  the  RPA  to  become  much  more  useful  for  combatant  commanders.  The 
same  process  of  integrating  Link  16  on  the  Predator/Reaper  can  be  used  to  inte¬ 
grate  air-to-air  or  new  air-to-ground  weapons.  Third-party  software  can  transpose 
real-time  aircraft  telemetry  data  into  weapons-employment-zone  validation  pro¬ 
grams  and  project  the  zone  on  the  customized  HUD,  ensuring  that  pilots  can 
quickly  release  weapons  on  cross-cued  targets  within  valid  employment  parame¬ 
ters.  Interlinking  also  offers  a  backup  to  loss  of  satellite  data  links.  The  aircraft 
could  still  retain  a  level  of  autonomous  functionality  for  full  motion  video  or  SIGINT 
collection,  shift  transmission  to  theater  nodes,  and  continue  to  slave  the  payloads  to 
cues  given  by  joint  partners  in-theater. 

Embracing  Leadership  in  Innovation 

The  AMPLEX  example  may  seem  ambitious— all  of  the  “what  ifs”  inherent  to  im¬ 
plementing  autonomy  in  a  weapon  system  create  a  general  perception  among  op¬ 
erators  that  this  kind  of  CONOPS  is  unachievable.  However,  the  responsibility  of 
creating  technological  solutions  to  enable  a  CONOPS  is  not  the  concern  of  opera¬ 
tional  squadron,  group,  and  wing  leaders.  They  have  a  blank  check  limited  only  by 
their  imaginations  when  influencing  a  new  CONOPS  and  should  state  the  norma¬ 
tive ,  optimal  way  of  things  rather  than  agonize  over  every  detail  of  how  other  units 
and  agencies  in  the  Air  Force  and  how  industry  will  attain  it.  With  a  clearly  defined 
CONOPS,  the  Air  Force  can  begin  writing  forward-looking  requirements,  and  indus¬ 
try  will  answer  the  call  under  normal  market  mechanics.  This  flow  is  how  large 
steps  in  technological  progression  occur:  not  by  looking  at  what  is  currently  on  the 
shelf  or  waiting  on  a  salesman  to  present  a  new  capability  and  figuring  out  a  way  to 
stitch  it  on  an  airplane,  but  by  conceptualizing  to  bridge  notional  applications  of 
technology  to  enable  tactics  that  will  vastly  improve  and  perhaps  completely 
change  the  way  the  Air  Force  does  business. 

Cost-effective  and  dramatic  improvement  in  capability  through  software  architec¬ 
ture  changes  and  digital  data-linking  of  RPAs  with  theater  assets  are  all  technologies 
ready  for  near-term  transition.  An  open-architecture  RPA  system  can  harness  the 
rate  of  technological  progression  and  reverse  the  current  acquisition  practices:  tech¬ 
nology  must  not  drive  requirements— the  opposite  should  be  true.  The  benefits  of 
such  a  program  not  only  will  reap  manpower  savings  through  automation  of  dull 
mission  sets  but  will  do  so  while  concurrently  multiplying  operational  capability. 

To  date,  the  current  emphasis  on  the  “culture  of  innovation”  in  the  Air  Force  has 
manifested  as  improvements  to  menial  processes.  Reorganizing  a  maintenance 
shop  to  reduce  an  Airman's  travel  between  stations,  claiming  hundreds  of  man¬ 
hours  saved  30  seconds  at  a  time,  or  streamlining  taxi  procedures  saving  a  minute 
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or  two  of  fuel  per  T-38  sortie  are  smart  moves  but  hardly  innovative.  An  AMPLEX 
program  will  present  a  substantial  step  forward  in  TTPs  and  operational  capability, 
not  through  employing  an  entirely  new  aircraft  acquisition  but  through  releasing 
the  current  sole-source  systems  to  an  open-software  architecture.  Only  when  Air 
Force  leadership  truly  enculturates  innovation  by  developing  forward-looking 
CONOPS  can  the  service  resume  its  responsibility  to  lead  industry  in  the  develop¬ 
ment  of  RPA  technology  and  break  free  of  the  sole-source  paradigm.  © 


Notes 

1.  Joint  Publication  5-0,  Joint  Operation  Planning,  11  August  2011,  1-5. 

2.  "MCL9A  Reaper/'  fact  sheet,  US  Air  Force,  23  September  2015,  http://www.af.mil/AboutUs/Fact 
Sheets/Display/ tabid/224/Article/104470/mq-9-reaper.aspx. 

3.  Thomas  P.  Ehrhard,  Air  Force  UAVs:  The  Secret  History,  Historical  Study  (Arlington,  VA:  Mitchell 
Institute  for  Airpower  Studies,  2010),  http://www.dtic.mil/get-tr-doc/pdfPAD  =  ADA525674. 

4.  Richard  Whittle,  "Hell fire  Meets  Predator,"  Air  &  Space  Magazine,  March  2015,  http://www.air 
spacemag.  com/flight-today /hellhre-meets-predator-1 80953940/ ?no-ist. 

5.  The  Air  Force  received  nearly  300  MQUB  Predators  between  program  inception  and  2011.  "Air 
Force  Accepts  Delivery  of  Last  Predator,"  GA-ASI  press  release,  7  March  2011,  http://www.ga-asi.com 
/air-force-accepts-delivery-of-last-predator. 

6.  John  Pike,  "RQU  Predator  MAE  UAV,"  FAS  Intelligence  Resource  Program,  6  November  2002, 
http:/  /  fas.org/ irp/ program/ collect/ predator.htm. 

7.  The  multiaircraft  control  station  allowed  one  pilot  to  distribute  control  of  up  to  four  aircraft  to 
sensor  operators  by  drawing  constrained  airspace  containers  called  sensor  operator  containers.  Once 
the  aircraft  was  within  the  container,  the  sensor  operator  could  command  aircraft  positioning  through 
point  click  loiters.  Employed  by  the  15th  Reconnaissance  Squadron,  this  capability  was  eventually 
abandoned  under  the  premise  that  pilots  could  not  cognitively  handle  multiple  aircraft  in  the  event  of 
simultaneous,  attention-demanding  maneuvers  such  as  emergency  procedures,  entry  into  restricted 
operation  zones,  or  attacks. 

8.  Lt  Col  Jerry  Brown,  multiaircraft  control  system  instructor,  personal  communication  with  the 
author,  3  October  2015. 

9.  Stephen  R.  Covey,  The  7  Habits  of  Highly  Effective  People:  Restoring  the  Character  Ethic  (New  York: 
Free  Press,  2003),  101. 

10.  SSgt  Adawn  Kelsey,  "RPA  Community  Launches  65th  CAP,  Meets  SecDef  Initiative,"  Creech  AFB 
press  release,  10  June  2014,  http://www.acc.af.mil/news/story.asp7id  =  123413492. 

11.  John  Keller,  "General  Atomics  to  Build  24  MQ_-9  Block  5  Reaper  Attack  Drones  in  $279.1  Million 
Air  Force  Contract,"  Military  and  Aerospace  Electronics,  5  February  2015,  http ://www.militaryaero space 
.com/ articles/2015/ 02/reaper-drone-order.html. 

12.  Hoffman,  "UAV  Pilot  Career  Field  Could  Save  $1.5B,"  Air  Force  Times ,  1  March  2009. 

13.  Sam  LaGrone,  "Navy  Conducts  Successful  Test  of  Aerial  Refueling  with  X-47B,  UCAS-D  Program 
Ending,"  USNI  News,  22  April  2015,  http://news.usni.org/2015/04/22/navy-conducts-successful-test 
-of-aerial-refueling-on-x-47b-ucas-d-program-ending. 

14.  John  Reed,  "USAF  Says  Adios  to  MCf-X,"  DoD  Buzz,  15  February  2012,  http://www.dodbuzz 
. com/2012/02/1 5/usaf-says-adios-to-mq-x/. 

15.  John  D.  Gresham,  "Details  of  the  X-47B’s  First  Autonomous  Carrier  Landing,"  Defense  Media 
Network,  11  July  2013,  http://www.defensemedianetwork.com/stories/details-of-the-x-47bs-hrst-auto 
mated-carrier-landing/ . 

16.  John  P.  Jumper,  "RPA  CONOPS  Effects  Scenarios,"  limited  circulation  white  paper,  14  March 

2011,  1. 

17.  John  R.  Boyd,  "Destruction  and  Creation,"  3  September  1976,  http://www.goalsys.com/books 
/documents/DESTRUCTION_AND_CREATION.pdf. 


1 04  |  Air  &  Space  Power  Journal 


Leading  the  Development  of  Concepts  of  Operations 


18.  Caroline  Rees,  “Predator  B  Demonstrates  Automatic  Tkkeoff  and  Landing  Capability,”  Un¬ 
manned  Systems  Technology,  25  September  2012,  http://www.unmannedsystemstechnology 
.com/ 2012/ 09/ predator-b-demonstrates-automatic-takeoff-and-landing-capability/. 

19.  “Gray  Eagle  UAS  Achieves  10,000  Automated  Tkkeoffs  and  Landings,”  fact  sheet,  GA-ASI,  25  July 

2012,  http:/ / www.ga-asi.com/ gray-eagle-uas-achieves-10000-automated-takeoffs-and-landings. 

20.  “AFRL  UAS  Roadmap,”  Air  Force  Research  Laboratory  /  XP  limited  circulation  publicly  released 
presentation,  March  2010. 

21.  Jeffrey  Eggers,  “A  Future  Vision  for  Unmanned  Systems  Operation  within  NATO:  Leveraging 
Autonomous  Behaviors  to  Manage  Complex  Systems,”  AF/A2Q  submission  to  NATO/OTAN,  1  May 

2013,  5. 

22.  Currently  the  MissionX  client  is  taught  as  part  of  the  732nd  Operations  Group  squadron’s  ad¬ 
vanced  tactics  course  as  a  viable  tool  for  advanced  multiship  tactics.  Additionally,  FocusedX,  a  deriva¬ 
tive  of  MissionX,  is  used  daily  by  aircrews  for  quick  reference  of  standoff  and  depression. 

23.  MissionX  client  was  developed  by  Capt  Brandon  Magnuson.  FocusedX  is  a  derivative  of  Mis¬ 
sionX  (later  adapted  as  a  plug-in  for  Raytheon-Solipsys’s  “Zeus”  software,  developed  by  Focused  Sup¬ 
port  LLC). 

24.  Google  Glass  is  an  optical  head-mounted  display  that  can  project  opaque  digital  data  into  the 
user’s  held  of  view. 

25.  The  MissionX  client  was  developed  entirely  in  Captain  Magnuson's  spare  time  and  transferred 
between  his  personal  and  government  computers  throughout  several  iterations  until  his  time  of  depar¬ 
ture  from  Creech  AFB,  NY. 


Capt  Curtis  G.  Wilson,  USAF 

Captain  Wilson  (BS,  Auburn  University;  MAS,  Embry- Riddle  Aeronautical  University)  is 
a  dual-qualified  MQ-1B  and  MQ-9A  mission  control  element  flight  evaluator,  MQ-9 
launch  recovery  element  pilot,  mission  commander,  and  chief  of  weapons  for  the  556th 
Test  and  Evaluation  Squadron,  Creech  AFB,  Nevada.  Formerly,  he  served  as  branch  chief 
of  MQ-1  weapons  for  the  867th  Reconnaissance  Squadron,  where  he  logged  over  2,000 
hours  executing  diverse  mission  sets  in  the  Predator  and  Reaper  systems.  Before  volun¬ 
teering  as  one  of  the  first  individuals  for  18X  Undergraduate  Remotely  Piloted  Aircraft 
Training,  Captain  Wilson  served  at  Wright-Patterson  AFB,  Ohio,  as  the  Air  Force  Re¬ 
search  Laboratory  (AFRL)  /  XP  unmanned  systems  portfolio  manager,  integrating  re¬ 
search  and  development  efforts  concerning  unmanned  aircraft  systems  across  the 
AFRL,  Office  of  the  Secretary  of  Defense,  and  NATO  partners.  He  also  served  as  the 
Block  5  Reaper  Systems  engineer  in  the  MQ-9A  system  program  office,  where  he  led 
developmental  efforts  such  as  auto  takeoff  and  land,  sense  and  avoid,  airworthiness 
certification,  and  special  programs.  Captain  Wilson  offers  a  rare  fusion  of  insight  from 
acquisition,  engineering,  test,  and  operational  experiences. 


Let  us  know  what  you  think!  Leave  a  comment! 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
http://www.airpower.au.af.mil 


Summer  2016  |  105 


